SYSTEMS AND METHODS FOR ENTERPRISE BASED 
ISSUANCE OF IDENTIFICATION CARDS 

Background of the Invention 

1. Field of the Invention 

The invention relates to production and issuance of embossed and/or encoded 
identification cards and more specifically relates to an enterprise-wide system for 
providing centralized control and management for issuance of such identification cards. 

2. Discussion of Related Art 

Issuance of identification cards is a critical task in many commercial and other 
endeavors. Exemplary of such endeavors are credit card issuance, debit card 
issuance, frequent customer identification card issuance, security card issuance, etc. 
Such identification cards often include embossed identification information and or 
digitally encoded identification information. Such digitally encoded identification 
information may be recorded on the identification card in a magnetic stripe or other 
storage medium as well as in so-called "smartcard" chips embedded within the 
identification card. 

Generation of such identification cards has long been the exclusive domain of 
complex, costly, large devices capable of both embossing the cards as well as 
programming digital identification information. In more recent years, devices for 
issuance of such identification cards have dramatically fallen in price as well as 
shrunken in physical size ("footprint"). For example, the model 150i embossing and 
encoding machine produced by Datacard Corp. of Minneapolis is a relatively low-cost 
device having a relatively small footprint (i.e., tabletop or desktop configuration). The 
Datacard 150i embossing and encoding machine is capable of producing such cards 
under control of an externally attached computing system such as a personal computer 
("PC"). 

Although older, larger devices were capable of producing much higher volumes 
of identification cards, the low-cost and small footprint of the Datacard 150i makes it 
possible to distribute such functions into more convenient localized facilities. Localized 



issuance of such identification cards is often referred to in the industry as "instant 
issuance." The paradigm of instant issuance allows for an identification card to be 
made while the user or customer waits rather than waiting days or weeks for a 
centralized facility to produce such card and ship the produced card to the end user. 

Although devices such as the DataCard 150i enable the decentralized issuance 
of identification cards, computing systems to permit such decentralized issuance of 
cards while maintaining centralized control of the information embossed and/or encoded 
on such cards were not available. 

The computing system called CardWizard® was produced and marketed by 
Dynamic Solutions International of Colorado in 1997. This computing system is 
comprised of a collection of interrelated software components designed to work in a 
distributed client/server model within a single location. Although designed in 
accordance with a single location client/server software model, when applied to a 
broader multi-location enterprise environment, a number of problems arise in this and 
other current solutions. 

1 . Financial identification cards require usage of highly sensitive data used for 
encryption calculations that produce values that are embossed and encoded on 
identification cards. This data is referred to as "encryption keys." To simplify 
software installation and provide greater security, large banking and other large 
financial enterprises prefer these encryption keys be stored at a single secured 
location within the network rather than at each location that has a card issuance 
machine. The original version of CardWizard®, like other present solutions, 
required these encryption keys to be stored at each location that had a card 
issuance machine. 

2. Administration and management problems arise where an enterprise may 
have different capabilities at each of several decentralized locations. For 
example, a large financial institution may issue ATM cards in one location and 
debit cards in a different location. It is therefore important for enterprise solutions 
to be easily configured, administered and managed to permit production of 
identification cards to be performed at a most appropriate location. 



3. Problems arise when decentralized locations, which cannot afford the cost of 
an issuance machine, wish to issue cards on an issuance machine located at 
another location within the network. 

4. Problems arise when locations want card production requests stored in a 
queue that allows cards to be produced at a later time at either their location or 
another location within the enterprise. 

5. Only a single card issuance machine is supported on a single PC. 

6. Support of external software processes in lieu of card issuance machines was 
not available. For example, rather than producing the card immediately at a card 
machine, it may be desired to route the card information to another computer 
system on the network for some other type of processing. 

7. Administration of card issuance machines, users, system access and 
production reporting and management of system options had to be done at each 
location rather than centrally. 

8. There are duplicate databases throughout the network, which increases 
exposure to fraudulent activities and required more systems administration 
activities to synchronize or replicate updated information. 

9. Having "self contained" card issuance systems at a single location presents 
the risk of someone stealing the equipment and potentially using it to make illegal 
financial cards. 



It is evident from the above discussion that a need exists for improved enterprise 
coordination in the production and issuance of embossed and/or encoded identification 
cards in a decentralized manner. 



Summary of the Invention 

The present invention solves the above and other problems, thereby advancing 
the state of the useful arts, by providing improved administration and management of 
decentralized identification card issuance in an enterprise-wide environment. In 
particular, the present invention includes features for using and managing multiple 
identification card production machines distributed throughout the enterprise and for 
routing of production requests for identification cards anywhere in the enterprise 
network. 

More specifically, a card machine controller component ("CMC") resides within a 
PC on the enterprise network and acts as a server at its physical location for connecting 
various configurations of card issuance machines and/or external software processes. 
Card issuance machines include devices such as the Datacard 150i while external 
software processes include tasks such as writing card information to a disk file or 
sending card information to another software application within the enterprise network. 
Multiple such card machine controller server components may reside in PCs dispersed 
throughout the enterprise network. The card issuance machine controller component 
communicates with client processes within the enterprise for purposes of producing 
identification cards at that location. 

As used herein, card issuance components includes card issuance machines 
such as Datacard products as well as other devices for creating identification cards and 
further includes external software processes for application specific custom software 
modules to create identification cards outside the scope of a particular machine. 
Further, as used herein, card issuance controller and CMC refer to a control module of 
the present invention that controls low level operations of one or more card issuance 
components. 

An administration component of the present invention interfaces with the single 
enterprise server component to coordinate access to centralized information required in 
production of cards and to permit enhanced management of the distribution of card 
production requests to appropriate card issuance machines in the enterprise. 

An aspect of the present invention enables a user-friendly graphical user 



interface to manage the definition of the entire enterprise's card production network. 
This definition includes configuration of each decentralized location including, but not 
limited to, the users, PCs, card issuance machines, which types of cards are allowed to 
be produced by a location and/or user and where each type of card will be produced. 
The graphical user interface ("GUI") allows an administrator to change the configuration 
as needed. For example, if it is desired to have future production of a type of card at a 
different card issuance machine, the administrator can use a simple drag and drop 
operation to effectuate this change. 

Another aspect of the present invention enables a user-friendly graphical user 
interface to manage the assignment and re-assignment of pending card production 
requests to appropriate card issuance machines distributed in the enterprise. The GUI 
allows an administrator to drag and drop card issuance requests presently assigned to a 
first card issuance machine to a different machine. This feature simplifies the 
management of the enterprise-wide production of identification cards by permitting the 
administrator to re-assign a production request to another issuance machine. For 
example, if a first issuance machine becomes inaccessible due to failure or is otherwise 
overloaded with requests, another machine at the same location or at another 
convenient location may be assigned the task of producing a queue of such requested 
cards. 

A still further aspect of the present invention lies in centralized security for the 
decentralized card issuance machines of the enterprise. A central administration 
component provides a central point of control for security including user ID's and related 
password protection for use of the card issuance machines and encryption of sensitive 
information exchanged between the enterprise server component and the distributed 
card machine controller components. 

The above, and other features, aspects and advantages of the present invention 
will become apparent from the following descriptions and attached drawings. 

Brief Description of the Drawings 

Figure 1 is a network diagram showing a sample enterprise configuration of the 
present invention. The diagram shows physical devices such as PCs and card issuance 
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machines in addition to the various software components installed within each PC. 

Figure 2 is block diagram showing the various software components in an 
enterprise card issuance environment using the present invention. The diagram shows 
communication paths between the various components. 
5 Figure 3 is a software flowchart of the operation for the enterprise server 

component for the present invention. 

Figure 4 is a software flowchart showing the enterprise server component's 
initialization logic. 

Figures 5 through 10 are exemplary graphical user interface display screens 
10 used in conjunction with the methods and structures of the present invention. 

Detailed Description of the Preferred Embodiments 

n While the invention is susceptible to various modifications and alternative forms, 

B a specific embodiment thereof has been shown by way of example in the drawings and 
ps will herein be described in detail. It should be understood, however, that it is not 
intended to limit the invention to the particular form disclosed, but on the contrary, the 
lj invention is to cover all modifications, equivalents, and alternatives falling within the 
7 s spirit and scope of the invention as defined by the appended claims. 



ylpo Figure 1 is a block diagram of a system 100 in accordance with the present 

^ invention. System 100 depicts a number of exemplary elements of the enterprise card 
P issuance system of the present invention. Those skilled in the art will recognize a wide 
variety of equivalent configurations and topologies in which the present invention may 
be advantageously applied. Specifically, the present invention accommodates a 
25 scaleable enterprise network utilizing client/server programming techniques well known 
to those skilled in the art. In such client/server programming paradigms, client 
processes and associated server processes may be co-resident within particular 
computing devices or may be widely distributed among a variety of computing devices 
of the enterprise communicating via a network communications medium and protocol. 
30 As shown in figure 1, all elements preferably communicate via TCP/IP communications 
network 150. 
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Within the present invention PCs are defined as members of "PC Groups". 
Normally a PC group consists of PCs residing at the same physical location. However, a 
PC group may consist of PCs located at different physical locations. In figure 1, there 
are three PC groups defined - "Central Operations" 162, "Location A" 160 and "Location 
5 B" 164. 

Enterprise server software component 130 residing in PC 110 at Central 
Operations location 162 provides centralized management and control for 
administration of system 100 in accordance with the present invention. The 
management and administration services provided by enterprise server 130 are 
10 accessed by administrative client 132 operable in PC 106, PC 110 and PC 112 in the 
various locations 160, 162 and 164, respectively. More specifically, administrator 
software component 132 provides a graphical user interface client process for an 
P administrative user to centrally control, configure, and manage system 100. 
:J PCs 102 through 108 and PCs 112 through 116 generally provide a client 

=pi5 process interface 134 for on-site requests for issuance of identification cards. PCs 106, 
jjj 108 and 116 further provide a direct interface to card issuance machines 120 through 
126. The interface to such card issuance machines 120 through 126 is provided by 
card machine controller component 1 36 operable within PCs 1 06, 1 08 and 1 1 6. 
n\ As noted above, those skilled in the art will recognize that the specific topology 

[j20 and configuration of system 100 in figure 1 is intended merely as exemplary of any 
g number of similar enterprise configurations. In particular, any number of PCs may be 
assigned to a particular PC group and any number of PC groups may be defined in the 
enterprise. The preferred physical locations of PCs is simply that which is convenient 
and beneficial for the enterprise and its customers. Similarly, the physical locations of 
25 card issuance machines 120 through 126 is that which is convenient for issuance of 
cards by the enterprise organization and further convenient for the enterprise 
customers. 

Figure 1 also indicates that each of card machines 120 through 126 may be 
designated for production of a particular type of identification card. For example, in a 
30 financial or banking enterprise application, particular card issuance machines may be 
designated for issuance of ATM cards while other card issuance machines may be 
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designated for issuance of ATM or debit cards. Card issuance machine 120 is 
designated in the exemplary enterprise of figure 1 as primarily a debit card issuance 
machine while card issuance machines 122, 124 and 126 are designated as primarily 
ATM card issuance machines. As above, the particular designation of each machine 
5 and its physical locations in the enterprise is that which is convenient and useful for the 
enterprise and its customers. Administrative, management and configuration functions 
provided by enterprise server software component 130 on PC 1 10 permit such flexibility 
in the location and designation of devices distributed in the enterprise. 

io Where figure 1 shows the overall architecture of an exemplary topology of an 

enterprise, figure 2 is a block diagram showing the functional relationship among all 
elements and processes operable within an enterprise exemplified in figure 1. An 
5 optional custom interface software component 152 is generally operable in conjunction 
!** with host system 202 and is preferably physically co-resident with enterprise server 
£ 15 software component 130 in a physical location 200 designated as the central operations 
ifi location. Remote locations are shown an exemplary single remote location 220 on 
figure 2. 

Optional security processor hardware element 208 operates in conjunction with 
u enterprise server software component 130 to provide requisite storage of a financial 
^20 institution's encryption keys and the encryption/decryption processes required by the 
r:i enterprise server 130. Encryption keys and related encryption rules can be maintained 
by an administrative user using the key manager element 138. These encryption keys 
and encryption rules are stored in either the optional security processor 208 or the card 
format database 214. 

25 The network configuration database 210 contains information used by the 

enterprise server software component 130 for management of the network and routing 
of card production requests to the proper card issuance device 236 at a remote location 
220 in the network. 

The card format database 214 contains definitions of various types of 
30 identification cards (also referred to herein as "card type" or "card type information" or 
"card format") available for production within the enterprise. Each production request 
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includes a corresponding card type indicating the type of card for which the information 
is to be produced. Each definition provides the rules and specifications for embossing 
and encoding the card. These rules are created and maintained by the designer 
component 154 and utilized by the enterprise server component 130 during the 
5 fulfillment of production requests submitted by client components 134, 140, 142 and 
150. In particular, standard client component 134 submits requests to produce a 
particular format of card. Such requests are produced by a user filling in a form on a PC 
in a remote location. Batch input client 140 generates a batch of card requests from a 
prepared file or database. Repin component 142 generates requests to change a 
10 personal identification number ("PIN") on a previously issued identification card. Such 
requests are typically processed at a special terminal device designed for the purpose 
of changing the PIN encoding on the card. 
T The CMC device "request queues" database 216 contains a collection of queues 

,j for each defined device assigned to the card machine controllers in the enterprise. 
;ji5 These queues provide temporary storage of card production requests received from 
yi client components 134, 140, 142 and 150 that are directed to a specific card issuance 
^ machine 236 or external software process 238. 

Optional production queue database 212 contains information used by the 
enterprise server software component 130 for temporary storage of card production 
%o requests received from client components 134, 140, 142 and 150 that are directed to a 
a specific production queue. Requests held in this production queue database 212 are not 
produced until requested by a user using the Administrator software component 224 at 
a remote location 220. At that time, the card will be produced at a card issuance device 
236 attached to a CMC software component 136 located at a remote location 220 
25 specified in the network configuration database 210. 

These centralized host based elements communicate via standard TCP/IP 
communications media and protocols with elements physically resident at each location 
220. A typical location 220 optionally may include a number of custom client user 
interface elements 150 and/or standard client user interface elements 134, 140 and 
30 142. Client user interface elements 150, 134, 140 and 142 provide the graphical user 
interface for customers and or enterprise customer service representatives to generate 
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and enter requests for production or repinning of identification cards. Such requests by 
client user interface elements 150, 134, 140 and 142 are directed via the network to 
enterprise server 130 typically resident in the central operations location 200. 

In addition to client user interface elements 150, 134, 140 and 142, elements 

5 224, 226 and 154 represent other standard interface elements provided at a remote 
location 220. Such standard elements may include components for administrative 
functions such as user maintenance, reporting and card stock inventory management 
(element 224); administration of a financial encryption keys (element 226); and design 
of specific card formats to be produced by the system (element 154). 

io For example, a particular location may design a new style or format of 

identification card, may issue requests for batches of identification cards to be 
produced, and may administer particular aspects of identification information and 
security information useful to service representatives at the particular remote location 
220 as well as useful to particular customers at that location. Such local management 

15 requests are also directed to enterprise server 130 through standard network 
communications. 

Though not required, a particular remote location 220 may provide a number of 
local card issuance machines 226 or external software processes 238. Such card 
issuance machines and external software processes are interfaced by a card machine 

20 controller (CMC) software component 136. Each CMC software component interfaces 
one or more appropriate card issuance devices or external software processes. 

A client user interface element 134, 140, 142 or 150 generates a request at a 
remote location 220 for issuance of a particular type of identification card. The request 
is forwarded to the enterprise server 130 located at a physical central operations 

25 location 200. The request is communicated via standard network communication media 
and protocols, preferably TCP/IP network protocols and associated network 
communication media. Information required for production of the requested 
identification card may be obtained locally by the client user interface element 134, 140, 
142 or 150 as well as centrally provided by operation of the enterprise server 130. For 

30 example, details of the particular customer or account information for the particular 
customer is preferably centrally stored at the central operations location and accessed 
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in a controlled manner through the optional Custom Interface software component 152. 
Any sensitive or confidential information transferred between the enterprise server 130 
and client user interface elements 134, 140, 142 and 150 and card machine controller 
element 136 is preferably encrypted to maintain security through the network. If the 
card is to be issued, the information necessary to emboss and/or encode the card is 
generated using the card format database 214. 

Card format database 214 contains definitions for each type of card known to the 
enterprise for production. This definition includes placement of information on a card, 
style of production of the information (i.e., encoded and/or embossing), application 
specific information (i.e., financial calculations relating to banking etc.), type of card 
stock/media (i.e., plastic embossed cards, magnetic stripes, "smart" cards, etc.) and 
other information required to generate any particular type of card used in the enterprise. 

Using the network configuration database 210 the enterprise server determines 
which card machine controller component and which card issuance device or external 
software process to use for the request. The information is then encrypted and 
transferred from the enterprise server 130 to the appropriate CMC software component 
136 in the enterprise. The card machine controller component 136 then communicates 
with the appropriate card issuance device 236 or external software process 238 to 
produce the card. Optionally, the information communicated to the card issuance device 
or external software process may also be encrypted for additional security. 

The server interface element 144 allows custom client user interfaces 150 to 
easily communicate with the enterprise server component 130 by providing a standard 
programming interface. The PIN pad interface OCX element 146 provides a standard 
programming interface between client components 134 and 150 and PIN entry 
machines 147. These PIN entry machines allow a customer to select their current PIN 
and optionally select a new PIN. The host interface OCX component 148 provides a 
standard programming interface between the custom client user interface 150 and the 
host system 202. This interface allows simplified transmission of information between 
the two elements. 

As noted above, those skilled in the art will recognize that the functional 
decomposition of elements and the physical locations of such elements as shown in 
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figure 2 is intended merely as exemplary of one preferred embodiment. The 
client/server programming paradigm permits the various client processes and server 
processes to be distributed anywhere in the enterprise network. Further, the specific 
breakdown of components may differ depending on specific design choices in 
5 implementing the features of the present invention. 

Figure 3 is a flowchart describing the operation of the enterprise server element 
depicted above figures 1 and 2. In general, the enterprise server process initializes 
when it commences operation and then awaits receipt of an event message indicative of 
10 an operation requested by a client process within the enterprise or from the enterprise 
server's internal clock timer. Requests are directed to the enterprise server from client 
user interface processes for production of cards and card machine controller elements 

□ as well as from the client administrative user interface for reconfiguration or other 

::. ill 

:f] management operations of the present invention. 

£:;15 Element 300 represents processing to initialize operation of the enterprise server. 

\f\ Among other functions, the initialization processing includes discovery and initialization 
;™ of card machine controller components in the network. Asynchronously, each card 
machine controller initializes each of the issuance machines or external software 
:~ s j processes it is designated to control. Further details of such initialization processing are 
^20 provided herein below with respect to figure 4. 

□ In the preferred embodiment, the server process awaits receipt of event 
messages from card machine controller processes with card production completion 
notifications and client processes requesting services from the enterprise server 
process. In addition, every two seconds, or other time interval so established, a timer 

25 event occurs and the server process checks each issuance machine queue to see if a 
card request needs to be processed. Element 302 therefore represents processing by 
the enterprise server process to await receipt of a supported timer event or a client 
initiated event message. Upon receipt of such an event, the method then continues by 
processing the received event in accordance with a type indicated therein. Exemplary 

30 of such client event messages in the preferred embodiment are: a client request to 
produce an identification card, an indication that production of a requested identification 
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card has completed, an administrative user client request to associate a newly designed 
card format with a particular issuance machine or its associated queue, and a request to 
administer, configure or manage the card issuance enterprise system of the present 
invention. 

Those skilled in the art will recognize that the particular events to be processed 
by the enterprise server are a matter of design choice in the implementation of the 
present invention. The particular events depicted in figure 3 are therefore intended 
merely as exemplary of typical events that may be processed by enterprise server 
operable in accordance with the present invention. Furthermore, those skilled in the art 
will recognize a variety of other programming paradigms useful in implementing features 
of the enterprise server. An event driven model as described herein with respect to 
figure 3 is therefore intended as representative of all such solutions. 

In response to a request to produce an identification card, elements 304 through 
314 are operable to process the request. Element 304 first checks the request to make 
sure all required information is provided (i.e., the request is valid). If the request is not 
valid element 306 is operable to notify the originating client of the problem and 
processing loops back to element 302 to await a next event. If the request is valid, 
element 308 next performs any requisite processing to calculate or reformat information 
for the card to be produced. For example, in financial applications of the present 
invention, ATM or credit cards have calculations involving customer PIN selection or 
assignment. Element 310 is next operable to determine whether the request is to be 
placed on a production queue for later processing or is to be routed to a queue 
associated with a card machine or external software process for processing. If routed to 
a production queue, element 312 is operable to queue the request on an identified 
production queue for later processing. If the request is to be processed now, element 
314 routes the request to the queue of the identified card machine or external software 
process. In both cases, processing loops back to element 302 to await a next event. 

Every two seconds, element 320 checks to see if more issuance machine 
queues need be checked. If all issuance machine queues have been checked 
processing completes for this timed event and continues at element 302 (label A) to 
await occurrence of another event. If more queues remain to be checked, element 322 
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gets information for the next card issuance machine queue. Element 324 then 
determines whether the card issuance machine or external software process associated 
with the queue or otherwise identified by the request is presently busy servicing other 
requests. If the machine or process is busy, processing continues by looping back to 
element 320 to check additional issuance machine queues. If the machine or process is 
not busy, processing continues with element 326 to unqueue the next request queued 
for the identified card issuance machine and transmit the unqueued request to an 
appropriate card machine controller responsible for controlling operation of the identified 
card issuance machine. Processing then continues by looping back to element 320 to 
determine if more queues remain to be processed. 

Processing by the card issuance machine proceeds asynchronously with respect 
to the enterprise server. Completion of the card production request will be signaled to 
the enterprise server by a subsequent event message as discussed below. 

In response to receipt of an event message signifying completion of an 
identification card production request, element 330 is operable to determine if the card 
was completed or an error occurred. If completed without errors, the client process that 
submitted the original request is notified of the completion with element 336 and then 
element 338 is operable to determine whether additional requests remain queued for 
the card issuance machine identified in the completion event message. If so, 
processing continues at element 340 to unqueue a next production request and transmit 
the request to the identified card machine controller and then loop back to element 302 
(label A) to await receipt of the next event. If no further requests are presently queued 
for the identified card machine, processing continues by looping back to element 302 
(label A). 

If element 330 determines that an error occurred in processing a request, 
element 332 is operable to notify the originating client process of the error. Element 334 
then suspends processing of further requests for this queue until the problem is 
corrected by an operator. Processing then continue by looping back to element 302 
(label A) to await receipt of another event. 

In response to receipt of an administrative reconfiguration or management event 
message, element 360 is operable to reconfigure the enterprise card issuance system 
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in accordance with parameters supplied in event message. As noted elsewhere herein, 
an administrative user of the enterprise server may reconfigure the system to associate 
particular PCs with particular PC Groups, to associate particular card issuance 
machines with particular PC Groups and PCs, to associate particular card formats with 

5 particular card issuance machines, etc. Processing then continues by looping back to 
element to 302 (label A) to await receipt of another event message. 

In response to receipt of an event message requesting a change in the routing of 
future card requests from one card issuance machine to another, element 370 is 
operable to so make this change. Element 372 then notifies the appropriate affected 

10 clients of the routing change. Processing then continues at element 302 (label A) as 
described above. Such a request may be initiated by an administrative client process in 
response to graphical input to "drag and drop" of selected routing definitions. 

Figure 4 is a flowchart describing additional details of the processing of element 

15 300 to initialize the enterprise card issuance system of the present invention. Element 
400 is first operable to open all system databases. Element 401 then identifies all card 
issuance machine controller elements present in the enterprise as defined in the system 
database (210 of figure 2). As noted above, a card issuance machine controller 
element is operable within a PC in locations that physically include card issuance 

20 machines. The card issuance machine controller element is a module operable in a PC 
at such a location to manage the production operations of one or more card issuance 
machines. The identity and location of all such card issuance machine controllers is 
used by the enterprise server to prepare its initial configuration information. 

Element 402 then creates a queue associated with each card issuance machine 

25 present in the enterprise system. Element 404 then determines whether all CMC 
components in the enterprise have been processed by elements 406 through 412. If no 
further CMC components remain to be processed, processing of element 300 is 
complete. If more CMC components are to be processed, element 406 is operable with 
respect to the next CMC component to attempt to establish a connection therewith. 

30 Element 408 then determines whether the attempted connection was successful. If not, 
processing of this CMC component is complete and processing loops back to element 
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404 to process additional CMCs. If the connection attempt succeeds, element 412 
transmits configuration information from the network configuration database (210 on 
figure 2) to the CMC component (136 on figure 1). This configuration information 
informs the CMC component of the types of card issuance machines attached to, or 
5 external software processes associated with the CMC component and the interfaces to 
be used (i.e., the physical and logical configuration of the CMC component and its card 
issuance machines and external software processes, elements 236 and 238 
respectively.) Processing then loops back to element 404 to process remaining CMC 
components. 

10 Those skilled in the art will recognize that the flowcharts of figures 3 and 4 are 

intended merely as representative of one exemplary embodiment of the enterprise 
server system of the present invention. A number of equivalent alternate embodiments 
will be readily apparent to those skilled in the art. Such design choices in 
implementation are well known to those of ordinary skill in the art. 

15 

Figures 5 through 10 are exemplary screen images depicting typical user 
interface techniques for implementation of the enterprise card issuance system of the 
present invention. In particular, these screen images are representative of screens 
typically used by an administrative user to configure and manage the enterprise card 

20 issuance system of the present invention. 

Figure 5 depicts elements and resources available in a typical enterprise system 
in accordance with the present invention. In figure 5, the first two elements 502 and 504 
identify production queues in which requests for associated types of cards are queued 
awaiting production by an assigned card issuance machine. In particular, the first 

25 queue 502 named "ATM Cards" is assigned to a card issuance machine named "Main 
Office\PC100\DataCard 28x/295." A second queue 504 named "Visa Debit Cards" is 
assigned to the same card issuance machine named "MainOffice\PC100\DataCard 
28x/295." A PC group 506 named "Branch 1" has two PCs 508 and 510 associated 
therewith and named "PC200" and "PC202." The PC group 506 does not have a card 

30 issuance machine. Two card formats 512 and 514 named "ATM Card" and "Visa Debit 
Card", are associated ("linked") with requests generated by clients operating on all PCs 
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of "Branch 1." All requests submitted for production of "ATM Card" card formats will be 
stored in the system production queue 502 named "ATM Cards." Similarly, all requests 
submitted for production of "Visa Debit Cards" will be stored in the system production 
queue 504 named "Visa Debit Cards." At some future time, an administrative user can 
5 instruct the system to produce the cards being stored in these production queues. In 
this example, both types of cards will be produced at the Datacard 28x/295 card 
issuance machine located in the Main Office as discussed below (i.e., the card issuance 
machine to which the production queue is currently linked). 

Figure 5 also identifies resources in a Main Office 516 including two PCs: 

10 element 520, named "PC100" and element 518 named "COMPAQ NT." Operable 
within PC 520 ("PC100") is a card machine controller 522 for controlling two card 
issuance machines, a Datacard 150i card issuance machine element 524 and a 
Datacard 28x/295 card issuance machine, element 526. Two card formats 528 and 
530, named "ATM Card" and "Visa Debit Card", respectively, are associated with PC 

15 Group 516 named "Main Office" for production on the attached DataCard 150i card 
issuance machine 524. 

The various elements of the enterprise are shown in a "tree" structure to reflect 
the physical and logical relationships among the elements. The physical relationships 
are the physical proximity of the elements. In other words, PCs that are members of the 

20 PC group "Main Office" are shown under the branches of the tree display rooted at 
element 516 "Main Office". In addition to PCs defined within each PC group are routing 
directives ("links") for the various card formats at either the PC group or PC level. These 
links specify either a particular card issuance machine or a specific production queue. 
Production queues, elements 502 and 504, are available for the entire enterprise 

25 and are linked, similar to how card formats are linked, to specific card issuance 
machines. However, card requests in the production queues are not produced until so 
directed by an administrative user at a later time. At that time, all card requests in the 
specified production queue will be produced at the currently linked card issuance 
machine. 

30 Card format and production queue links are logical relationships that the 

administrative user can create and modify using simple drag and drop manipulations on 
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the displayed graphical tree structure. For example, in order to create a new card format 
link and associate it with a card issuance machine queue an administrative user would 
perform the following exemplary steps on the graphical user interface shown in the 
following figures. 

1. As shown in Figure 6, right click on element 602 which defines a PC group 
named "Main Office". 

2. A popup menu appears as shown in Figure 7. 

3. Click on the popup menu choice "New Card Format Link..." element 702 on 
Figure 7. 

4. A window appears as shown in Figure 8. 

5. Select the card format to create a link. In this example we select "Visa Credit 
Card", element 802 and then click on the OK button element 804. 

6. The card format link appears in Figure 9 as element 904 with a link definition 906 
as "Needs to be linked". 

7. The user clicks on the icon for the link, element 904, and drags the icon to the 
icon element 902 that represents the card issuance queue for a particular card 
issuance machine. 

8. When the icon being dragged is released, the card format is linked to this queue 
as indicated by the link definition 1006 "Main Office\PC100\DataCard 28x/295)" 
in Figure 10. 

While the invention has been illustrated and described in detail in the drawings 
and foregoing description, such illustration and description is to be considered as 
exemplary and not restrictive in character, it being understood that only the preferred 
embodiment and minor variants thereof have been shown and described and that all 
changes and modifications that come within the spirit of the invention are desired to be 
protected. 



